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ABSTRACT 

The  3PA  system  is  an  Intriguiging  study  in  implementation 
failure  and  success.   The  Production  Planning  and  Profit  Analysis  system 
was  introduced  into  two  manufacturing  plants  in  the  same  division  of  a 
company.   It  was  readily  accepted  in  one  plant  and  staunchly  resisted  in 
the  other,  in  spite  of  repeated  managerial  interventions.   Eventually, 
however,  the  resisting  plant  gave  in  and  began  using  the  system.  What 
makes  this  case  especially  interesting  is  that  top  management  clearly 
supported  the  system  and  gave  both  plants  the  opportunity  to  participate 
in  the  design  process;  conventional  wisdom,  therefore,  helps  little  to 
explain  the  early  resistance  in  one  plant.  While  It  is  true  that  the 
resisting  plant  did  not  avail  itself  of  the  proffered  participation 
opportunity,  analysis  of  the  case  data  through  a  political  perspective 
indicates  that  the  lack  of  participation  is  not  so  much  a  cause  of  the 
resistance  observed,  but  a  reflection  of  the  political  situation  in  the 
company  to  which  the  resistance  is  more  appropriately  attributed.   This 
paper  describes  the  political  perspective,  applies  it  to  the  3PA  case 
and  draws  some  implications  for  practicing  system  designers  and  Imple- 
mentors. 
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THE  CASE  OF  THE  3  PA  SYSTEM 


Today,  the  General  Manager  and  staff  of  the  EP  Division  at  JHM, 
Inc.,  believe  their  3PA  system  to  be  a  success.   However,  at  various 
points  in  time  over  the  course  of  system  development,  the  outcome  had 
not  always  seemed  so  certain.   Careful  planning  had  failed  to  anticipate 
or  avoid  several  irritating  setbacks,  but  these  were  finally  overcome, 
through,  it  was  believed  by  managers  at  JHM,  sustained  attention  and 
managerial  action.   A  brief  history  of  these  events  follows. 

V/hen  Jim  Reason  took  over  the  newly-formed  EP  Division  at  JHM 
in  late  1973t  he  knew  he  faced  a  challenge  to  his  managerial  abilities. 
The  two  major  plants  in  the  division,  Athens  and  Capital  City,  were 
located  80  and  300  miles  away  from  corporate  headquarters.   Each  plant 
performed  a  different  stage  in  the  production  of  the  metal  aircraft 
parts  which  were  the  Division's  major  products;  Athens  cast  the  parts 
from  molten  metal  and  then  shipped  them  to  Capital  City  where  they  were 
machined  and  finished.   But  the  relationships  between  the  plants  were 
not  good,  due  in  part  to  historical  reasons  and  in  part  to  economic 
ones.   At  one  point  in  time,  both  plants  had  had  forging  operations 
which  had  competed  with  each  other  for  customers.  This  history  had 
politicized  the  relations  between  the  plants,  making  cooperation  and 
information-sharing  difficult  at  best.   Currently,  because  of 
uncertainties  in  its  production  process  which  created  a  scrap  rate  of 
40^,  Athens  was  rarely  able  to  meet  the  production  deadlines  it  promised 
Capital  City.   Finally,  because  of  differences  in  history  and 
technology,  each  plant  had  developed  different  accounting  and  reporting 


conventions  which  made  it  difficult  for  them  to  communicate  vrtth  each 

other  and  for  Division  Headquarters  to  compare  reliably  the  figures 

submitted  by  them. 

Prior  to  the  formation  of  the  new  Division,  Capital  City  had 

been  part  of  another  Division  in  JHM.   It  had  been  started  up  to  handle 

overflow  from  a  plant  near  Corporate  Headquarters;  it  had  always 

maintained  good  relations  with  people  from  JHM.   It  was  believed  to  be 

a  well-managed  plant.   Its  profit  picture  was  good,  and  it  had  few 

problems  with  labor  unrest.   Consequently,  JHM  did  not  make  many 

attempts  to  intervene  in  its  internal  affairs,  a  situation  obviously 

facilitated  by  the  300  mile  distance  between  it  and  headquarters.  The 

plant  manager  there  prior  to  1973  apparently  aimed  to  avoid  headquarters 

intervention  at  almost  any  cost,  even  the  cost  of  suppressing 

information  automation. 

"The  old  plant  manager  used  to  give  as  little  cost 
information  to  headquarters  as  he  could  get  away 
with.  You  see,  he'd  been  burned  in  the  past,  by 
telling  his  boss  some  unfavorable  news  and  having  it 
used  against  him.   He  kept  a  real  lid  on  MIS  .  .  . 
He  was  afraid  that  if  headquarters  found  out  that  he 
had  certain  regular  accounting  reports,  they  would 
demand  to  see  them.  So  he  allowed  systems  develop- 
ment only  grudgingly  and  then  he'd  say:   'don't 
breathe  a  word  of  this  to  headquarters'." 

According  to  Jim  Reason,  when  he  became  Division  Manager:  "The  Capital 

City  Plant's  idea  of  a  long-range  plan  was  three  months  out."  Because 

of  this,  Jim  Reason  and  his  small  staff  expected  resistance  from  Capital 

City  when,  immediately  after  taking  office,  he  began  proposing 

computer-based  systems  "to  integrate  the  division".   This  fear  was 

exacerbated  by  the  existence  of  a  strong,  old  fashioned  centralized 

production  control  function  at  Capital  City.  (See  Figure  1  for 

organizational  chart.) 
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When  the  plant  manager  died  in  1975,  Jim  Reason  appointed 
Dudley,  who  took  it  as  a  personal  challenge  to  bring  information  systems 
at  Capital  City  "out  of  the  dark  ages".   In  this  goal,  he  was  aided  by 
the  systems  people  at  Capital  City  who  desired  the  opportunity  to 
experiment  with  the  state-of-the-art  and  to  support  manufacturing 
applications  in  addition  to  accounting  applications. 

Prior  to  the  formation  of  the  Division  in  1973.  Athens  had  had 

a  very  different  history  from  Capital  City.   An  autonomous  company. 

Athens  was  acquired  by  JHM  and  allowed  to  operate  on  its  own  for  ten 

years.   In  the  late  sixties.  JHM  began  more  active  intervention  into  its 

affairs,  removing  its  sales  force  and  its  substantial  computer 

operations  and  consolidating  these  with  other  groups  at  the  Division  and 

Corporate  level  respectively.   In  spite  of  its  history  of  labor  unrest 

and  poor  management,  of  low  profit  and  bad  quality.  Athens  was  quite 

sophistocated  in  computerization. 

"They  had  their  own  computer,  which  was  really 
quite  large  for  a  facility  of  its  size.   The 
applications  they  developed  were  mostly 
accounting-oriented,  but,  around  1968.  they 
tried  an  experiment  in  shop  floor  data 
collection." 

The  system  in  question  computerized  inventory  control.  Terminals  were 
placed  on  the  factory  floor  and  trained  operators  entered  production 
data  into  them.   Three  or  four  people  were  employed  in  the  office 
full-time  to  maintain  data  accuracy. 

In  1971,  JHM  sent  a  team  of  managers,  including  Fob  Frisco,  to 

Athens . 

"My  job  was  to  install  JHM's  control  system, 
which  wasn't  being  used  at  Athens.   There  was  an 
inventory  loss  on  these  books  over 
one-and-a-half  million  dollars.   One  of  the 
first  things  I  did  was  to  pull  out  those 


computer  terminals,  because  the  reporting  of 
inventory  was  woefully  inaccurate  ..."  I  set 
about  putting  in  a  sound  system  of  time-keeping 
and  inventory  control." 

The  "sound  system  of  time-keeping  and  inventory  control",  was  the 

computerized  WIP  (work  in  process)  system.  Many  people  at  Athens  felt 

this  system  was  largely  accounting-oriented  and  did  not  give  enough 

information  for  effective  production  control.   However,  the  V/IP  had  the 

distinct  advantage  of  eliminating  from  the  books  the 

over-one-million-dollar  inventory  loss,  since  that  had  proved  to  be  only 

a  paper  loss,  caused  by  improper  record-keeping.  People  also  complained 

that  Frisco  eliminated  the  jobs  of  those  people  who  maintained  Inventory 

records,  but  Frisco  explained  that: 

"...  this  was  a  time  of  tremendous  layoffs  — 
we  let  500  people  go.  Without  a  doubt  the  staff 
functions  were  shorthanded.  There  was  talk  at 
the  time  of  eliminating  the  entire  MIS 
operation." 

The  Athens  Plant  barely  survived  the  recession  of  the  early  seventies; 

it  did  so  at  the  cost  of  severe  cutbacks  to  staff  support,  especially 

production  control. 

In  1973,  the  EP  Division  was  formed,  and  Jim  Reason  was 

appointed  division  manager.  He  selected  a  small  staff,  naming  Bob 

Frisco  his  financial  manager,  and  set  about  shaping  up  his  two 

ill-assorted  plants  into  a  division.   This  process  took  two  forms: 

the  development  of  a  computer-based  system  to  integrate  the  plants  and 

additional  managerial  intervention  at  Athens.   Reason  knew  that  it 

should  be  possible  to  forecast  profit  (or  loss)  from  a  forecast  of 

sales,  data  about  production  plans  and  historical  part  cost  trends. 

Thus  was  born  the  idea  for  3PA.   But  such  a  system  required  consistent 

production  control  procedures  throughout  the  Division.   It  was  decided. 


therefore,  that  the  first  priority  was  the  development  of  a  production 

control  system  which  contained  an  inventory  of  work  in  process  and 

shipping  and  manufacturing  schedules.   Reason  initiated  development  of 

the  PCS  system  within  a  few  months  of  starting  his  job  and  then  set 

about  the  task  of  turning  around  the  performance  of  the  Athens  plant. 

The  latter  task  entailed  a  major  reorganization  of  Athens' 

internal  organizational  structure  in  1975  (see  Figure  2).   Prior  to  this 

time,  Athens  was  structured  in  a  functional  manner,  virtually  identical 

to  Capital  City  (see  Figure  1).   The  reorganization  carved  up  the  plant 

into  four  product  lines  and  distributed  several  staff  functions  across 

these,  including  engineering  and  inventory  control.  According  to  one 

source : 

"The  split  up  into  product  lines  was  a  bitch. 

Production  control  was  the  first  one  to  feel  the 

pinch.  They  had  a  feeling  of  lost  prestige  and 
power." 

Compared  to  this  and  compared  to  the  many  horror  stories  in  the 
MIS  literature,  the  process  of  developing  the  3PA  system,  which  began 
with  the  development  of  a  production  control  system  in  late  1973f  was  a 
model  of  good  system  development.   According  to  one  division  staffer: 
"we  did  everything  right".  A  planning  group  was  formed,  composed  of  a 
representative  of  Corporate  Management  Information  Systems,  a  Sales 
coordinator  and,  from  each  Plant,  a  systems  person  and  the  production 
control  manager.   This  group,  subject  to  the  review  of  Reason,  two  of 
his  staff  and  the  two  plant  managers,  had  the  charter  to  develop  a  PCS 
"which  will  be  compatible  with  the  needs  of  all  the  personnel  in  the 
division."  The  planning  group  chose  meeting  sites  equidistant  between 
the  plants  and,  for  a  year,  held  two-day  sessions  monthly  to  discuss 
their  common  and  unique  problems. 


Representatives  from  the  Athens  Plant  generally  hung  back  in 

these  meetings,  but  those   from  the  Capital   City  Plant  "really  took  the 

ball  and  ran  with  it."     The   Capital   City  production  control  manager 

assumed   project  management  responsibility.     Working  closely  with  a 

systems  person  from  Capital   City,  he  developed  the  project  team's 

proposal . 

"We  didn't  want  to  use  conventional  file 
management  techniques.   If  we  had  done  it  that 
way,  we  wouldn't  have  the  state-of-the-art  and 
we  Just  would  have  had  to  convert  it  later. 
Then  it  would  never  be  right.  We  wanted  to  use 
data  base  management  techniques.  We  wanted 
on-line  processing  and  inquiry."   (data 
processing  specialist) 

And  staff  managers  at  Capital  City  were  anxious  to  see  that 

manufacturing  was  supported  through  computer  systems:  all  prior 

computerization  had  been  applied  to  the  accounting  department.  Taking 

stock  of  their  needs.  Capital  City  Plant  people,  from  production 

planners  to  accountants  to  systems  specialists,  were  unanimous  in  their 

definition  of  the  "ideal"  system. 

"I  want  a  womb-to-tomb  MRP  system.  Something 
which  will  take  the  production  plan  and  a  bill 
of  materials  and  tell  me  when  I've  got  to  make 
it,  and  when  I've  got  to  ship  it,  how  much  to 
keep  in  inventory  and  when  to  order  raw 
materials",   (production  controller) 

In  the  middle  of  1975,  the  planning  group  presented  to  the 

review  cottmittee  the  recommendation  that  the  EP  Division  undertake 

development  of  an  MRP  (materials  requirements  planning)  system  using 

data  base  management  technology.   This  system  would  have  added  an 

engineering  bill  of  materials  to  the  production  schedules  and  inventory 

status  of  a  simple  production  control  system;  it  would  have  calculated 

purchasing  requirements  as  a  by-product  of  its  operation.   They 
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estimated  a  two-year  completion  date  for  the  proposed  system.   Reason 

was  upset  and  impatient  with  the  recommendation:  he  had  already  waited 

a  year  and  the  proposed  MRP  seemed  to  go  far  beyond  what  was  needed  for 

divisional  forecasting.   The  project  group  was  directed  to  develop  a  PCS 

which  would  be  ready  in  one  year  from  this  date. 

The  abbreviated  schedule  forced  the  project  team  to  abandon 

much  of  the  planned  MRP,  although  they  did  receive  grudging  approval  to 

use  the  data  base  technology  that  would  enable  linking  the  PCS  to 

forecasting  and  costing  systems. 

"They  gave  in  vrtien   Reason  realized   that  a  data 
base   system  would  allow  on-line  access  to  the 
data.     We  wouldn't  have  this  if  we  had   just  tied 
into  Athens'   systm,   which  was  a  typical  batch 
system." 

To  save  time,  they  based  the   PCS  on  a  work  in   process   (WIP)   system  that 

had  been  automated  at  the  Athens   Plant   in   1971,   prior   to  the   formation 

of  the  EP  division. 

"The  management  review  committee  wouldn't  buy  it 
(our  recommended  MRP  system).      They  wanted   the 
system  now  ...   So  they  said    'What  can  you  do 
in  one  year?     We  want  a   production  control 
system  by  October,    1975!'    ...   So  we  took  the 
logic   from  the  Athens  WIP  and  used  it  almost 
intact." 

This  WIP  was  streamlined   somewhat  and   adjusted   to  accomodate  conditions 

at   Capital   City.      The  new  PCS  was  up  and  running  by  early   1976  at 

Capital   City,   but   Athens  continued   to  use   its  old  WIP,   claiming  problems 

in   the  new  system.      The   situation  was  generally  ignored.      Until   the 

forecasting  system  was  ready,   Athens'    failure  to  use  the   system 

presented   no  major   problems. 

Project  review  in  mid-1976  disclosed   that  the  project  team  had 

failed   to   proceed   with  developing  the   forecasting  and   costing  elements 


intended  to  interface  with  PCS.   Instead,  the  team  had  continued  to  work 

on  "operational  systems,"  tackling  small  enhancements  that  made  PCS 

easier  to  use  or  more  useful  in  the  plant  production  control 

environment.   The  review  coimittee  believed  the  team  had  lost  sight  of 

its  charter.   Reason's  information  needs  were  not  being  addressed;  he 

said: 

"They  fed  back  to  us  what  they  were  doing, 
telling  us  what  they  wanted  to  do  next.   I  said, 
•where  are  my  needs?  I  want  a  management 
exception  report  for  use  by  me  and  the  plant 
managers.  I  want  a  tool  to  help  me  manage  the 
division  better.   If  we  had  listened  to  the 
system  that  Capital  City  proposed,  we'd  not  have 
been  able  to  do  the  3PA.  They  couldn't  get 
together  on  it." 

Reason's  accounting  manager,  Bob  Frisco  opened: 

"It  was  an  excellent  case  of  bad  communication. 
I  thought  I  had  explained  to  the  project  team 
what  I  wanted.  I  wanted  my  own  system  for  cost 
and  financial  analysis  that  managers  could  use. 
But  they  hadn't  made  any  allowance  for  this. 
They  had  redefined  the  project  in  terms  of  what 
they  did  in  production  control." 

The  project  leader  was  removed,  replaced  by  Frisco  himself,  who 

negotiated  with  Reason  a  July,  1977,  deadline  for  completion  of  the 

forecasting  and  costing  components  of  the  system.   It  was  at  this  time 

that  the  name  3PA  was  coined,  standing  for  production,  planning  and 

profit  analysis. 

In  July  1977,  Frisco  reported  that  programming  the  remainder  of 

3PA  was  slightly  behind  schedule  (but  not  over  budget).   The  balance  of 

the  progress  report  focussed  on  the  disappointing  lack  of  utilization  of 

the  PCS  system  by  the  Athens  Plant.   Wrote  Frisco:   "The  interest  is 

just  not  there."  This  lack  of  interest  became  an  issue  later  in  1977 

when  the  forecast  was  "turned  on"  and  Athens'  data  was  discovered  to  be 
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inaccurate.   Division  headquarters  had  begun  to  make  plans  and  decisions 

on  the  basis  of  3PA  forecasts  once  these  became  available  to  them. 

After  a  while,  staffers  discovered  bad  data  in  the  3PA  data  base,  which 

they  traced  to  the  Athens  plant.  A  phone  call  or  two  succeeded  in 

convincing  Athens  to  "clean  up"  the  data,  but  this  sequence  had  to  be 

repeated  several  times.  A  division  staffer,  sent  to  investigate  the 

matter,  discovered  that  Athens'  pattern  of  using  PCS  was  unorthodox. 

Athens  was  continuing  to  maintain  its  own  computerized 

inventory  system,  dating  back  to  1971,  as  the  basis  for  its  internal 

decision-making.   It  was  entering  data  into  PCS  merely  to  comply  with 

the  Division's  wishes.  The  problems  in  the  divisional  data  base  arose 

because  the  new  system  required  different  update  procedures  from  the 

old.   Naturally,  Athens  was  somewhat  more  conscientious  about  the  system 

they  used  than  they  were  about  PCS.  Specifically,  their  old  system  was 

updated  in  a  weeky  batch  run.  PCS  was  designed  to  be  updated  nightly, 

but  Athens,  when  it  did  so  at  all,  updated  the  PCS  system  on  the  same 

schedule  as  its  old  system. 

"The  problems  came  in  with  the  changes  (i.e. 
modifying  the  inventory  status  of  a  part  after 
taking  physical  inventory).  When  there  were 
changes,  they  only  made  these  to  the  old  system, 
the  one  they  used.  They  didn't  bother  to  enter 
these  into  the  tube,  which  they  never  looked  at. 
The  IMS  data  base  got  more  and  more  out-of-date. 
But  that  was  never  too  much  of  a  problem  until 
recently,  when  we  tried  to  hook  up  the  3PA 
forecast  with  PCS.  Before  that,  every  six 
months  or  so,  in  response  to  complaints  from 
division  staff,  they'd  simply  clean  out  the 
whole  data  base  and  reload  it  with  a  picture  of 
the  current  WIP  (work  in  process) ,  but  they 
never  really  maintained  the  data  base." 
(systems  person) 

Further,  Athens  continued  to  perform  its  production  scheduling  manually, 

claiming  that  the  system  omitted  certain  needed  computations  and  failed 
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to  provide  the  "pinkie  report",  used  by  production  controllers  to 

identify  what  parts  should  be  shipped. 

At  this  point.  Division  Staff  were  forced  to  admit  that  the 

unexpected  had  happened.   Athens,  not  Capital  City,  was  resisting  a 

system  based  on  one  already  in  use  (and  without  resistance)  at  Athens. 

"I  don't  remember  exactly  how  we  solved  the 
problem.   I  remember  telling  Frisco  that  they 
had  six  months  to  start  using  it  or  I'd  have 
their  systems  guys  down  there  start  reporting 
directly  to  him."  (division  manager) 

In  early  1978,  a  programmer  new  to  Athens,  acting  on  directions  from  the 

division, 

"fixed  it  so  that  the  inventory  transactions  go 
directly  into  the  IMS  data  base  and  then  from 
there  into  Athens'  old  programs.  Now  they  get 
their  old  reports,  and  we  get  their  data. 
Except  for  the  daily  update,  they  hardly  know 
the  difference.   The  change  is  transparent  to 
the  user."  (systems  person) 

Division  staffers  called  this  implementation  strategy  "pulling  the  plug 

on  their  old  systems".  And  it  had  the  effect  of  ensuring  Athens' 

compliance  without  changing  Athens'  behavior  around  data  entry  to  the 

inventory  system.  But  Athens  still  did  not  use  the  computerized 

scheduling,  so  headquarters  escalated. 

"In  the  last  one  and  one  half  to  two  years,  our 
way  of  dealing  with  the  problems  at  Athens  was 
to  say,  'by  the  following  date,  we  expect  you  to 
be  at  such  and  such  a  place  with  the  system.' 
They'd  come  back  to  us  and  say,  'we  can't  use 
it,  because  it  doesn't  give  us  what  we  need!   So 
we  went  back  and  gave  them  the  reports  they 
wanted  in  the  format  they  wanted.   But  it  still 
wasn't  enough! 


In  early  1979,  Division  headquarters  sent  a  "fixer"  down  to  Athens. 

"What  does  (the  EP  Division  staff  manager  on 
•special'  assignment)  do?  Well,  you  have  to 
see  him  to  appreciate  him.   He  does  whatever 
he  needs  to  do.   If  he  needs  to  listen,  he 
listens.   If  he  needs  to  shout,  he  shouts.   He 
just  goes  there,  and  whatever  it  is  that  needs 
to  get  done,  gets  done.   He's  the  fixer." 
(division  staff  manager) 


Shortly  thereafter,  coincident  with  a  general  upturn  in  business 
conditions,  production  controllers  in  the  high  volume  product  lines  at 
Athens  started  using  3PA's  computerized  schedules.   The  production 
controllers  in  low  volume  lines  continued  to  schedule  manually. 
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THE  POWER  DISSONANCE  EXPLANATION  OF  RESISTANCE 


The  case  of  3PA  appears  to  provide  additional,  unnecessary 
support  for  the  results  of  numerous  MIS  research  studies  and  the 
guidelines  of  conventional  wisdom:   successful  implementation  of  a  MIS, 
defined  in  terms  of  user  satisfaction  and  system  acceptance  (the 
opposite  of  resistance),  requires  top  management  support  and  user 
participation  in  the  design  process.   In  the  case  of  3PA,  the  Division 
Manager  initiated  the  project,  supported  it  through  to  completion  and 
initiated  corrective  actions  every  time  the  project  appeared  to  get  off 
course.  Further,  users  were  offered  the  genuine  opportunity  to 
participate,  including  time  away  from  regular  work  duties;  and  in  spite 
of  persistent  problans,  3PA  was  ultimately  declared  successful. 
Therefore,  It  is  tempting  to  view  the  case  of  3PA  as  supporting 
traditional  notions  of  the  causes  of  resistance  and  traditional 
prescriptions  of  how  to  avoid  it  and  ensure  success. 

The  case  of  3PA  also,  however,  offers  support  for  an  additional 
explanation  of  resistance,  based  on  the  concepts  of  power  and  politics, 
which  can  explain  more  data  and  which  has  implications  different  from 
those  of  the  traditional  explanation.   Consider  several  problems  with 
the  traditional  explanation.   In  the  first  place,  it  implies  that  user 
participation  is  sufficient  for  acceptance.   Participation  convinces 
reluctant  subordinates  to  acquiesce,  but  even  more  important,  ensures 
that  the  system  designed  fits  the  needs  of  the  participators,  thereby 
overcoming  potential  resistance  and  instilling  a  sense  of  commitment  to 
the  final  product.   Therefore,  MIS  practitioners  are  urged  to  ensure 
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user  participation.   Yet,  practitioners  cannot  ensure  participation,  but 
can  only  offer  the  opportunity  to  participate,  and  the  case  shows 
clearly  that  the  opportunity  alone  is  not  sufficient.   Athens  had  the 
same  opportunity  as  Capital  City,  but  did  not  take  it.   This  leads  one 
to  ask  whether  there  is  a  factor,  other  than  paticipation ,  which  is  the 
real  cause  of  the  observed  resistance  or  acceptance.   If  there  is  such  a 
factor,  it  may  lead  to  recommendations  for  practitioners  which  do  not 
depend  upon  things  outside  their  control,  as  does  the  recommendation  to 
ensure  user  participation. 

Second,  the  traditional  explanation  implies  that  one  factor 
(Athens'  lack  of  participation)  caused  Athens'  resistance  but  that  a 
different  factor  (sustained  managerial  attention)  later  caused 
acceptance.   Surely,  a  simpler  explanation  would  point  to  the  working  of 
a  single  factor  which  itself  changed  or  vrtiich  faced  changed 
circumstances  over  time,  rather  than  to  the  operation  of  two  or  more 
different  factors  at  different  times.   By  simplifying  the  explanation  of 
resistance  in  this  way,  more  useful  recommendations  may  be  possible. 

None  of  this  is  meant  to  deny  that  involving  users  in  the 
design  of  an  MIS  is  a  useful  tactic  that  can  improve  the  chances  of 
successful  implementation.  It  does  imply,  however,  that  the  tactic  may 
be  inappropriate  or  unsuccessful  in  some  cases,  and  that  the  traditional 
explanation  offers  little  guidance  here,  since  it  prescribes  user 
participation  in  every  case,  regardless  of  the  type  of  system  being 
implemented.   An  explanation  of  resistance  based  on  some  other  factor 
may,  in  contrast,  provide  insight  into  those  occasions  when 


participation  is  likely  to  help.   It  may,  therefore,  explain  in  the  case 
of  3PA  why  Athens  alone  did  not  avail  itself  of  the  opportunity  to 
participate  offered  both  to  it  and  to  Capital  City. 

An  alternative  explanation,  which  addresses  all  of  these 
objections,  explains  resistance  to  information  systems  as  a  lack  of 
consonance  between  the  distribution  of  power  implied  by  an  information 
system  and  the  distribution  of  power  existing  in  the  organization. 
Thus,  the  origins  of  resistance.   Here,  power  is  defined  as  the  ability 
to  get  one's  way  over  objections.  Thus,  the  origins  of  resistance  are 
found,  not  in  the  presence  or  absense  of  any  particular  tactic  for 
introducing  change,  but  in  the  interaction  of  the  substance  of  the 
change  with  its  organizational  context.  Clearly,  the  power  distribution 
of  an  organization  is  not  the  only  substantive  dimension  which  could  be 
changed  by  the  introduction  of  a  system  with  certain  design  features. 
Other  dimensions  include  the  task  variety,  importance  and  autonomy  of 
middle  managers'  Jobs  and  social  interaction  patterns  or  Job-related 
communication  channels.  But  organizational  power  structures  influence  a 
great  deal  of  the  behavior  of  individuals,  groups,  and  subunits 
contained  in  them.  Therefore,  power  structure  changes  introduced  by 
computer-based  systems  comprise  an  efficient  and  fruitful  starting  point 
for  identifying  the  organizational  impacts  of  systems  and,  hence,  the 
causes  of  resistance  to  them. 

Computer-based  systems  can  threaten  change  in  the 
organizational  power  structure  in  one  or  more  of  three  distinct  ways, 
any  one  of  which  is  alone  sufficient  to  produce  resistance  of  the  type 
observed  in  the  case  of  3PA.   The  first  way  in  which  information  systems 
interact  with  intraorganizational  power  stems  from  the  use  of  systems  in 
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decision-making.   Implied  in  the  adage  "information  is  power"  is  the 

ability  of  individuals  to  influence  the  outcome  of  decision  processes  if 

they  control  access  to  information  used  to  define  decision  criteria  or 

to  evaluate  alternatives  against  these  criteria.  The  informational 

aspects  of  power  are  discussed  in  Pettigrew  (1972),  and  Pfeffer  (1981), 

among  others. 

An  example  of  the  ability  of  information  systems  to  confer  or 

deny  interorganizational  power  through  access  to  data  was  given  by  a 

staff  member  of  the  EP  Division. 

"Actually,  I  remember  we  were  quite  surprised 
when  it  turned  out  that  Athens  opposed  the 
system.  We  had  expected  more  problems  at 
Capital  City.  Why?  Because  at  Capital  City, 
old  Oscar  has  been  the  production  controller  for 
twenty  years.  He  keeps  all  the  numbers  in  hip 
head,  and  he  calls  all  the  shots.  No  one  can 
argue  with  him  when  he  says  'we  need  this'  or 
'we  only  have  that'.  Oscar's  vacations  are 
events  to  be  planned  for  months  in  advance." 

In  other  words,  Oscar  had  power  because  he  had  control  over  and 
sole  access  to  data  bases  containing  information  about  inventory, 
schedules  and  deliveries,  upon  which  smooth  operation  of  the  plant 
depended.   Pbwer  positions  like  Oscar's  are  valued  by  many  people  and, 
once  attained,  are  unlikely  to  be  gracefully  relinquished  to  the 
"imperatives"  of  progress  and  automation. 

Oscar,  for  his  part,  was  not  insensitive  to  these  issues.  When 
questioned,  he  explained  that  his  role  was  to  balance  the  demands  of 
company  salesmen  against  the  desires  of  the  plant  for  smooth  running 
operations,  a  task  which  required  the  exercise  of  considerable 
"influence".  His  original  concerns,  on  learning  about  the  plans  for  the 
new  system,  were  that  salesmen  would  have  direct  access  to  data  which 
would  tell  them  what  the  plant  was  really  able  to  produce.  This  would 
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encourage  salesmen  to  ask  for  more  than  they  actually  needed,  giving 

them  a  safety  margin  to  the  detriment  of  the  plant.  But  then,  Oscar 

explained,  he  realized  that  the  salesmen  would  have  access  only  to  the 

data  that  Oscar  entered  Into  the  system,  an  arrangement  which  differed 

only  in  medium  from  his  prior  ability  to  present  information  in  a  way 

that  gave  him  maximum  leverage. 

"I  got  to  have  my  kitty.  But  you  see  that 
number?  What  is  it?  A  500?  Well,  I  know 
that  500  is  really  a  100.   Now,  is  that  a 
kitty  or  isn't  it?" 

Clearly,  Oscar  lost  none  of  his  former  power  through  the 
introduction  of  the  3PA  system  at  Capital  City,  but  the  example 
illustrates  one  way  in  which  systems  can  work  against  the  perceived 
self-interests  of  certain  people  in  an  organization.  By  changing  who 
has  access  to  what  information  or  who  has  control  over  key  data  bases,  a 
management  information  system  can  alter  power  bases,  disturbing  patterns 
of  communication,  influence,  decision-making  in  an  organization  and 
consequently  altering  prestige  and  status. 

The  second  way  in  which  information  systems  Interact  with 
intraorganizational  power  stems  from  the  use  of  systems  to  change  the 
behavior  of  individuals  and  the  performance  of  the  organization.  For 
example,  a  data  base  may  describe  the  performance  of  individuals  or 
departments.  Access  to  this  data  is  usually  coterminous  with  the 
ability  to  use  it  for  evaluation  and  to  allocate  rewards  and  punishments 
based  on  the  evaluations.   For  another  example,  a  data  base  may  describe 
the  state  of  the  organization's  productive  capacity  or  of  its 
environment.  Access  to  this  data  may  enable  one  to  define  the  key 
problems  and  opportunities  facing  the  organziation  and  give  one  the 
information  necessary  to  cope  with  these.   If  one  is  sufficiently 
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convlncing  about  the  ability  to  deal  with  internal  and  external 
uncertainties,  one  can  wield  substantial  power  among  colleagues  in  this 
way. 

Thus,  the  power  to  influence  individual  and  organizational 
performance  conferred  by  specific  design  features  of  an  information 
system  is  virtually  analogous  to  that  described  by  an  organization 
chart.   Indeed,  many  computer-based  systems,  particularly  operational  or 
transaction-oriented  systems  like  accounting  systems,  production 
scheduling  and  control  systems  and  order  processing  systems,  spell  out  a 
pattern  of  authority  for  control,  decision-making  and  resource 
allocation  which  is  virtually  -a  miniature  organization  chart.  When  the 
distribution  of  power  and  influence  embodied  in  the  information  system 
differs  from  that  in  the  formal  structures,  the  formal  structures  are 
challenged.   To  the  extent  that  computer-based  systems  succeed  in 
channeling  behavior,  formal  structures  will  erode.   The  structural 
aspects  of  power  are  discussed  in  Crozier  (.^96>^)   and  Hlckson  et  al. 
(1971),  in  Conrath  and  du  Roure  (1978),  Markus  (1980)  and  Markus  and 
Pfeffer  (1981),  as  well  as  in  an  extensive  literature  on  the  effects  of 
computers  on  organizational  centralization,  reviewed  in  Robey  (1977), 
Pfeffer  (1978)  and  Bariff  and  Galbraith  (1978). 

An  example  of  the  ability  of  infomiatlon  systems  to  confer  or 

deny  power  through  the  evaluation  and  altering  of  individual  and 

organizational  behavior  can  be  found  in  these  words  of  the  Capital  City 

Plant  Manager: 

"When  I  first  heard  about  3PA,  It  was  described 
as  a  divisional  need.   It  could  help  us  make 
better  centralized  decisions  for  the  division. 
The  system  has  some  features  which  relate  to 
centralized  control,  for  example,  the  forecast. 
But  there  are  problems  with  this.   The  ability 
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to  track  our  performance  back  to  the  forecast  is 
a  nebulous  thing.   It  gets  awkward.   The  problem 
is  that  we  get  evaluated  against  the  forecast 
Sales  makes  for  us.   The  fear  is  that  we  will  be 
held  accountable  piece  by  piece,  rather  than  for 
just  the  overall  dollar  figure.  That  we  don't 
mind  being  held  accountable  for.   But  if  they 
hold  us  accountable  by  the  piece,  and  if  Sales 
doesn't  sell  exactly  the  mix  they  predicted, 
we're  in  for  it.   The  fear  is  that  there  is  a 
lack  of  flexibility  in  the  forecast.   3PA  is  a 
centralized  system,  but  it  can  be  much  more 
useful  to  us  on  a  decentralized  basis." 

The  third  way  in  which  information  systems  interact  with 
intraorganizational  power  is  by  symbolizing  power  and  by  presenting  the 
image  of  the  ability  to  influence  outcomes,  regardless  of  the  actual 
intention  or  ability  to  do  so.  Systems  symbolize  power  through  language 
and  tangible  accoutrements;  they  suggest,  imply,  seem  and  appear  through 
their  names,  their  terminals,  their  printouts,  their  manuals  and  their 
proponents,  independent  of  the  tasks  they  accomplish.  Secretaries  at 
word  processing  terminals  may  be  renamed  "workstation  professionals", 
but  managers  may  resent  the  clerical  connotations  of  the  same  electronic 
mail  terminals  in  their  own  offices.  A  construction  engineering  firm 
may  automate  engineering  designs  to  impress  clients;  a  welfare  agency 
may  find  that  a  computerized  case  tracking  system  helps  convince  funding 
sources  that  services  are  provided  efficiently  even  though  Internal 
operations  do  not  change  (Kling,  1978).   Ihe  image  of  physician  as 
healer  who  treats  each  unique  patient  may  be  shattered  by  the  presence 
of  a  system  reporting  patients'  statistical  prognoses  (Markus  and 
Pfeffer,  1981).   The  organizational  power  structure  is  partially 
revealed  through  language  and  symbols,  rituals  and  ceremonies;  computer- 
based  systems,  likewise,  have  symbolic  aspects  and  accompaniments.   When 
the  images  of  systems  diverge  from  those  of  their  organizational 
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context,  the  existing  structures  are  affronted.  The  symbolic  aspects  of 

power  are  discussed  in  Pfeffer  (1981)  and  applied  to  information  systems 

in  Markus  and  Pfeffer  (1981). 

An  example  of  the  ability  of  information  systems  to  confer  or 

deny  power  symbolically  can  be  found  in  the  objections  to  3PA  raised  by 

production  controllers  at  Athens.  Oi  the  surface,  these  objections 

dealt  with  the  ability  or  inability  of  the  system  to  accomplish  its 

objectives. 

"We  can't  use  the  Production  Plan  as  the  basis 
for  a  forecast,  because  the  Production  Plan  is 
based  on  the  PCS.   If  the  inventory  (in  PCS)  is 
inaccurate,  which  it  is,  then  the  Pro- 
duction Plan  is  meaningless.  Therefore,  the 
forecast  is  meaningless." 

But  the  PCS  was  virtually  identical  to  Athens'  old  inventory  system; 

therefore,  the  controllers  were  saying  that  under  both  old  and  new 

systems,  the  data,  which  was  their  responsibility  to  maintain,  was  not 

accurate.  This  was  not  strictly  true,  as  the  controllers  did  have 

accurate  knowledge  of  inventory  positions.  But  they  maintained  this 

knowledge,  not  through  a  carefully-kept  perpetual  inventory,  as  the  new 

system  implied,  but  by  going  out  to  the  floor  and  physically  counting 

whenever  the  need  arose.   In  their  minds,  the  new  system  offered  the 

promise  (image)  of  better  inventory  management  without  the  substance 

they  believed  essential  to  the  task,  a  substance,  incidentally,  which 

could  be  found  at  Capital  City,  where  a  strong,  centralized  production 

control  group  had  the  resources  to  use  a  PCS  effectively: 

"I  got  to  have  control  of  the  inventory  on  the 
floor.   I  got  to  know  where  the  product  is.   You 
got  to  have  people  to  police  the  reports,  to 
correct  the  'negatives'  which  mean  you  got  an 
error.  Today  we  got  to  go  over  to  the  inventory 
guy  and  'blue  sky'  it.  We  say  'this'  should 
probably  be  a  'that'.  At  Capital  City,  they're 
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dolng  really  well  with  3PA.   You  want  to  know 
why?  Because  they  have  a  guy  running  3PA 
full-time  and  runners  to  go  out  and  check  the 
minuses.   They  have  centralized  inventory 
control  at  Capital  City  and  proper  controls  on 
the  data.   They  have  people  there  to  check  the 
job  tickets.  .   .  Without  support  like  Capital 
City  has,  I'll  probably  end  up  keeping  my  manual 
records  and  throwing  the  3PA  stuff  in  the  trash" 
(production  controller). 


Computer-based  systems,  then,  can  interact  with  organizational 
power  structures  in  three  ways,  by  allocating  control  over  and  access  to 
information,  by  setting  up  formal  structures  of  performance  evaluation 
and  action  initiation  and  by  symbolizing  certain  values  or  images.   From 
the  political  perspective,  resistance  to  computer-based  systems  can 
occur  when  a)  the  information  access  channels,  b)  responsibility 
structures  or  c)  the  symbols  created  by  an  information  system  diverge 
from  the  channels,  structures  or  symbols  of  the  larger  organizational 
context  in  which  the  system  is  used.  Any  one  of  these  three  sources  of 
system-induced  organizational  dissonance  is  sufficient  to  cause 
resistance  to  a  system.  And  resistance  can  occur  independent  of  user 
participation  and  top  management  support.  Users  may  unwittingly 
participate  in  the  creation  of  an  organizationally-dissonant  system 
design  which  they  later  resist  when  its  implications  are  felt. 
Organizationally  appropriate  designs  are  frequently  adopted  willingly 
regardless  of  who  suggested  them  or  developed  the  specifications.   The 
presence  or  absence  of  implementation  tactics  like  user  participation 
cannot  produce  accepted  or  successful  systems  in  and  of  themselves,  but 
they  may  be  instrumental,  in  a  secondary  way,  in  affecting  the  degree  to 
which  a  computer-based  system  matches  or  diverges  from  the 
organizational  power  structure. 
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Armed  with  this  background  on  the  political  explanation  of  MIS 
implementation,  the  3PA  case  can  be  analyzed,  accounting  for  the 
objections  to  the  traditional  explanation  proposed  at  the  beginning  of 
this  section. 
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POWER  ANALYSIS  OF  THE  3PA  CASE 


A  power  analysis  of  the  3PA  case  must  explain  two  different 
sets  of  behavior:   first,  why,  initially,  did  Capital  City  accept  the 
system  while  Athens  resisted  it  and,  second,  why  did  Athens  begin  using 
it  eventually.   Several  things  should  be  made  clear  regarding  these 
points.   In  the  first  place,  the  same  system  was  installed  in  each 
plant.   Features  complained  about  by  Athens'  production  controllers  were 
also  noticed  and  disliked  by  those  at  Capital  City,  but  did  not  affect 
their  usage  of  the  the  system.  Further,  the  system  resisted  at  Athens 
was  nearly  identical  to  another  system  in  use  at  Athens  without  evidence 
of  resistance.   In  the  second  place,  controllers  at  Athens  had 
successfully  resisted  several  applications  of  managerial  pressure;  it  is 
unlikely  that  their  sudden  capitulation  reflected  a  direct  response  to 
one  more  edict. 

In  the  preceding  section,  in  the  discussion  of  the  structual 
aspects  of  power  and  information  systems,  3PA  was  described  as  a  system 
which  allowed  Division  Headquarters  the  ability  to  monitor,  evaluate  and 
reward  the  performance  of  the  plant  managers  and  to  Intervene  in  their 
operational  plans  around  production  and  shipping.   Thus,  the  system 
strongly  centralized  authority  in  the  division  compared  to  the  prior 
situation  in  which  the  plants  had  been  relatively  free  to  act  on  their 
own.   This  lack  of  consonance  between  the  structural  power  in  the 
organization  and  that  implied  by  the  system  would  lead  to  the  prediction 
that  both  plants  would  resist  it,  but  in  fact  only  Athens  did.   In  large 
measure,  this  is  due  the  fact  that  Capital  City  was  able  to  avoid 
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substantial  power  loss  with  respect  to  Headquarters,  because  it  had 
maintained  a  strong  centralized  production  control  function  (see  Figure 
1  and  the  discussion  of  informational  power).  Athens,  on  the  other 
hand,  was  not  able  to  avoid  a  power  loss  because  its  centralized 
production  control  group  had  been  splintered  (by  Divisional  edict)  into 
four  smaller  product  line  groups  of  one  person  each  (see  Figure  2). 
Embedded  as  they  were  in  subunits  under  the  influence  of  product  line 
managers  and  engineers,  the  production  controllers  at  Athens  were  unable 
to  present  a  united  front  toward  Headquarters  and  toward  their  own  plant 
managers  and  lacked  both  the  image  and  the  actual  resources  they  felt 
were  necessary  in  their  role  (see  discussion  of  the  symbolic  base  of 
power).   In  summary,  then,  the  3PA  system  threatened  a  loss  of  power  to 
Headquarters  in  both  plants,  but  at  Capital  City,  unlike  Athens,  there 
were  structures  in  place  to  minimize  this  loss. 

Perhaps  even  more  important ,  however ,  the  3PA  system  threatened 
a  loss  of  power  for  Athens  with  a  corresponding  gain  in  power  for 
Capital  City  in  terms  of  there  relationships  with  each  other.  In  other 
words,  it  can  be  argued  that  Capital  City  had  something  to  gain  from 
centralized  managerial  control  which  would  reduce  Capital  City's 
dependence  on  Athens.   It  will  be  remembered  that  the  Capital  City  plant 
was  on  the  downstream  side  of  Athens  in  the  process  of  producing  the 
parts  they  jointly  manufactured;  Capital  City  received  parts  from  the 
Athens  Plant  and  finished  them.  Athens'  investment  casting  technology 
was  highly  uncertain  and  the  scrap  rate  was  high.   Therefore,  it  was 
difficult  for  Athens  to  meet  the  delivery  dates  it  promised  Capital 
City,  since  many  parts  had  to  be  reworked.   Dependent  customers  (like 
Capital  City)  had  little  choice  but  to  wait,  for  there  was  no  substitute 
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for  the  capital-intensive  operations  performed  at  Athens.   In  contrast, 
the  nature  of  Capital  City's  technology,  machining,  was  such  that  most 
of  the  plant's  customers  could  do  it  themselves;  what  they  wanted  from 
Capital  City  was  low  cost  and  timely  service.   On  both  of  these 
dimensions,  the  performance  of  Capital  City  depended  on  Athens,  who  had 
little  incentive  to  perform  in  ways  favorable  to  Capital  City;  Athens 
was  too  preoccupied  with  its  own  problems  which  did  not  include  cost  and 
delivery. 

From  this  point  of  view,  the  Capital  City  Plant  was  dependent 
on  Athens,  which  gave  Athens  a  favorable  power  position.   In  the  past, 
Athens  had  been  able  to  maintain  this  advantage  by  controlling  access  to 
information  about  its  progress  toward  schedules:   to  have  released 
accurate  information  would  have  made  Athens  vulnerable  to  pressure  from 
Capital  City.  The  3PA  system,  unlike  Athens'  existing  V/IP,  gave  data 
about  the  actual  progress  of  Athens  toward  its  production  schedules  not 
only  to  Division  Headquarters  but  also  to  the  Capital  City  Plant.   It 
was,  then,  in  the  interest  of  Capital  City  to  support  a  system  that 
would  reduce  its  dependence  and  in  the  Interests  of  Athens  to  resist  a 
system  that  would  decrease  its  power.   This  analysis,  showing  how  3PA 
altered  the  existing  power  balance  between  the  two  plants,  explains  why 
the  identical  system  was  resisted  in  one  plant  and  accepted  in  another. 
It  is  not  that  Capital  City  was  insensitive  to  problems  with  3PA  such  as 
the  lack  of  the  pinkie  reports.    Rather,  this  inconvenience  was  a  small 
price  to  pay  for  reducing  a  fundamental  dependence  on  its  sister  plant. 

The  next  issue  to  be  addressed  by  the  power  analysis  is  why 
Athens  finally  began  using  3PA.  The  obvious  answer  is  that  the  heat 
from  headquarters  became  unbearable.   But  this  answer  sounds  a  little 
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weak  in  the  context  of  almost  two  years  of  ingenious  resistance  by  the 
production  controllers  who  were  required  to  input  the  necessary 
schedules.   A  more  appropriate  conclusion  seems  to  be  that,  in  197Q,  use 
of  3PA's  production  schedules  gave  production  controllers  a  power 
advantage  that  they  did  not  have  without  3PA,  and  that  this  power 
advantage  had  not  existed  for  them  in  1978. 

This  is  not  as  farfetched  as  it  sounds.   In  1978,  Athens  was 
experiencing  an  economic  slump;  volume  of  business  was  low,  so  low  that 
much  production  scheduling  could  be  done  "in  the  head",  given  some 
reasonable  estimates  of  current  inventory.   Those  estimates  were  formed 
by  going  out  to  the  floor  and  counting,  rather  than  through  the  use  of 
PCS  or  its  predecessor,  the  WIP.   By  early  1979,  however,  business  had 
picked  up  considerably,  and  there  was  no  way  to  keep  track  of  everything 
manually.   In  early  1979,  several  production  controllers  at  Athens  were 
observed  to  be  using  3PA  in  direct  proportion  to  the  number  of  products 
for  which  they  were  responsible:   frequency  and  quality  of  use  varied 
with  number  of  products  and  volume  of  business.  The  system,  by  giving 
them  the  ability  to  cope  with  uncertainty,  gave  them  some  of  the 
organizational  power  they  had  long  wanted.   (This  is  the  structural 
aspect  of  power.) 

The  3PA  system  did  not  give  the  production  controllers 
everything  they  wanted,  additional  people  or  additional  influence  with 
their  plant  manager.   But  when  the  economic  upturn  came,  they  were  too 
busy  to  worry  about  it  anymore.  With  the  change  in  business,  3PA  became 
their  only  way  to  cope.   It  is  interesting  to  note  that  they  believed 
their  eventual  adoption  of  the  system  to  be  voluntary,  and  it  irritated 
them  that  Headquarters  took  credit  for  the  change  of  behavior. 
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"....Now  they  think  we're  using  it  just  to  make 
them  feel  good.   You  can't  win." 

In  summary,  changing  economic  conditions  changed  the  context  in 

which  the  3PA  system  was  used  by  production  controllers  at  Athens. 

Their  consequent  acceptance  of  the  system  cannot,  in  entirety,  be 

interpreted  as  a  yielding  to  management  influence,  but  rather  as  an 

indication  of  a  change  in  the  informational,  structural  or  symbolic 

aspects  of  power  which  had  caused  their  initial  resistance. 

IMPLICATIONS 


The  power  dissonance  explanation  identifies  the  causes  of 
resistance  in  the  degree  to  which  a  system  conflicts  with  the  existing 
power  structure  in  the  organization  using  the  system.  Systems  can 
conflict  with  organizational  power  structures  in  any  or  all  of  three 
ways:  by  changing  patterns  of  access  to  and  control  over  information, 
by  altering  formal  authority  for  performance  evaluation  and 
responsibility  for  action  initiation,  and  by  symbolizing  values  and 
images  at  odds  with  those  accepted  in  the  organizational  culture.  And, 
as  the  analysis  of  the  3PA  case  shows,  the  power  dissonance  explanation 
can  account  for  observed  patterns  of  resistance  and  acceptance  entirely 
without  reference  to  aspects  of  the  implementation  process,  whether  top 
management  support  or  user  participation  tactics  are  at  issue. 

Some  implications  of  this  perspective  of  resistance  are  clear. 
If  the  goal  of  a  manager  or  systems  analyst  is  to  introduce  a 
computerized  system  while  avoiding  resistance,  care  should  be  taken  to 
analyze  the  organizational  context  of  system  use  and  to  ensure  that 
specific  details  of  the  system's  design  match  that  context  along  three 


-27- 


dimensions:   patterns  of  access  to  and  control  over  data,  allocation  of 
authority  and  responsiblity  for  performance  evaluation  and  action-taking 
and  symbolic  content.   In  the  cases  where  this  is  the  goal  of  managers 
or  system  designers,  the  tactic  of  user  participation  can  be  a  valuable 
way  to  ensure  consonance  between  system  and  organization,  because  users 
will  tend  to  design  into  a  system  current  organizational  power 
relationships  and  cultural  values.   Less  resistance  will  be  likely,  not 
because  of  the  tactic  per  se ,  but  because  the  tactic  tends  to  produce 
organizationally  consonant  designs.   The  opposite  effect  will  be 
achieved,  however,  if  the  manager  or  analyst  fails  to  include  some  key 
users,  such  as  those  who  must  enter  data  into  the  system,  or  gives 
disproportionate  weight  to  the  recommendations  of  users  who  are  trying 
to  improve  their  own  power  positions  through  the  design  of  the  new 
system. 

For  those  who  are  attempting  to  make  systems  that  are 
organizationally  consonant,  some  additional  lessons  from  the  3PA  case 
concern  the  importance  of  history.   It  will  be  recalled  that  the  power 
analysis  of  the  case  relied  on  the  facts  that  3PA  altered  the 
traditional  power  relations  between  the  plants,  to  Athens'  disadvantage, 
and  between  the  plants  and  headquarters,  in  ways  with  which  Capital  City 
but  not  Athens  was  able  to  cope  effectively.   In  the  first  place,  almost 
all  of  the  data  required  to  perform  this  power  analysis  refers  to 
aspects  of  the  histories  of  the  plants  prior  to  their  incorporation  in 
the  EP  Division.   It  is  unlikely  that  a  systems  analyst  assigned  to  the 
3PA  project  in  197M  or  1975  would  bother  to  inquire  about  Athen's  status 
as  a  private  company  in  I960  or  the  plants'  history  of  competitive  and 
antogonistic  relations.   Even  if  an  analyst  knew  this  history,  from  long 
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experience  in  the  company,  this  is  not  the  sort  of  data  which  systems 
analysts  have  typically  been  trained  to  recognize  as  important  or  to 
incorporate  in  their  designs.   Yet,  Just  such  information  provides  the 
key  to  the  problems  encountered. 

In  the  second  place,  part  of  Athens'  resistance  to  3PA  is 
related  directly  not  to  the  3PA  -  PCS  implementation  effort  which  was  so 
carefully  handled,  but  to  the  history  of  first  JHM's,  then  EP 
Division's,  intervention  into  the  internal  workings  of  that  plant,  which 
was  a  not-so-carefully  handled  implementation  process.   One  outcome  of 
this  process  was  to  break  up  the  strength  of  Athens'  production  control 
function  in  ways  that  were  inconsistent  with  the  new  system 
substantively,  symbolically  or  both.   But  these  events  were,  in 
appearance,  unrelated  to  PCS  and  3PA,  and  a  systems  analyst  would  not 
normally  inquire  into  them  or  factor  them  into  Systems  designs.  Yet, 
these  aspects  of  history  were  clearly  interrelated  with  the  resistance 
observed . 

Thirdly,  this' organizational  history  is  Important,  not  only  for 
understanding  why  Athens  resisted  and  Capital  City  accepted  the  3PA 
system,  but  also  for  understanding  why  Athens  did  not  and  Capital  City 
did  participate  in  the  system's  design.   Under  the  circumstances, 
beleaguered  by  economics  and  by  Corporate  Headquarters,  Athens  probably 
perceived  no  real  opportunity  to  influence  the  situation  facing  them. 
Capital  City  on  the  other  hand,  had  the  slack  resources  and  a  positive 
motivation  to  influence  events.   It  is  in  the  context  of  the  political 
and  economic  events  preceding  an  implementation  effort  that  evidence  of 
disposition  to  participate  can  be  found. 
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Therefore,  the  wise  systems  analyst,  designer,  or  Implementor , 
whether  a  manager  or  a  technician,  will  reconstruct  a  history  of 
organizational  events,  climates  and  past  "systems"  projects  which  could 
have  some  bearing  on  current  Implementation  efforts.   A  history, 
carefully  prepared  and  analyzed  from  a  political  perspective,  will 
substantially  enhance  the  ability  of  the  analyst  either  to  produce  a 
system  design  generating  less  resistance  or  to  structure  a  design 
process  that  will  yield  a  better  design. 

The  preceding  recommendations  were  based  on  the  assumption  that 
the  goal  of  a  manager  or  systems  analyst  is  to  reduce  resistance  to  a 
new  system.  Obviously,  however,  the  goals  of  system  implementors  will 
frequently  involve  making  changes  In  the  existing  organizational 
information  flows,  power  channels  or  value  systems,  and  to  follow  the 
preceeding  recommendations  will  not  achieve  the  desired  results.   In 
this  case,  the  greater  the  dissonance  between  the  existing  organization 
and  the  proposed  system,  the  greater  the  need  for  implementation  tactics 
based  on  power  and  politics,  such  as  those  described  In  detail  by 
Pfeffer  (1981). 

Frequently,  when  political  implementation  strategies  are  called 


for,  the  use  of  user  participation  is  as  a  tactic  is  strongly  counter- 
indicated,  in  direct  contradiction  to  much  prevailing  MIS  wisdom.  This 


is  so  for  two  reasons.  First,  if  users  are  given  a  genuine  opportunity 
to  participate,  they  will  try  to  change  the  proposed  designs  in  ways 
which  meet  their  needs  to  the  exclusion  of  others,  which  can  lead  to  the 
failure  of  managers  and  systems  analysts  to  achieve  their  "political" 
(i.e.  requiring  change  in  the  three  power-related  dimensions  of  the 
organization)  objectives.   This  can  be  clearly  seen  in  the  process  of 
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designing  the  3PA  system,  where  Capital  City  "took  the  ball  and  ran  with 

it"  and  pursued  their  objectives  for  a  womb-to-tomb  MRP  as  long  as  they 

were  in  control  of  the  design  process.  Divisional  staff  members  had 

repeatedly  to  bring  their  own  objectives  to  the  attention  of  the  design 

group  and  were  ultimately  forced  to  take  over  direct  project  management 

to  ensure  the  outcome  desired.  The  ultimate  system  had  a  distinct 

accounting  orientation,  reflecting  the  biases  of  the  last  project 

manager  and  fell  far  short  of  Capital  City's  wishes.   In  the  process. 

Capital  City's  plan  for  an  integrated  operational  production  system  went 

to  the  back  burner,  where  it  still  simmers.  Capital  City's  plant 

manager,  Dudley,  remarked: 

"We  were  disappointed  that  the  Division  would 
not  give  us  the  resources  to  develop  the  system 
we  need  to  run  our  plant  properly.  But  I  would 
have  done  the  same  thing  if  I  were  in  Reason's 
place.  I  would  have  made  sure  I  got  what  I 
wanted  out  of  it  first.  But  we  have  the 
beginnings  of  what  we  need,  and  we  will  get  the 
rest  of  it,  though  it  may  take  us  twenty  years. 

Second,  user  participation  is  strongly  counter  indicated  In 
situations  where  the  dissonance  between  the  organization  and  the 
proposed  system  is  great,  because  people  asked  to  participate  under  such 
conditions  may  rightly  feel  that  they  are  being  manipulated  into 
recommending  a  solution  they  would  not  like;  this  feeling  is  likely  to 
generate  as  much  resistance  as  the  disliked  solution.  Much  has  been 
written  about  the  dangers  of  "pseudo-participation",  intended  to  give 
people  the  feeling  of  participation  without  the  genuine  potential  to 
influence  substantive  outcomes.   Cummings  and  Malloy  (1973),  for 
example,  have  cautioned  against  using  participation  as  an  implementation 
strategy  in  climates  of  low-trust  among  the  parties  and  when  the  outcome 
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of  the  design  process  is  a  foregone  conclusion. 

VHien  Bob  Frisco  took  over  the  management  of  the  3PA  project,  he 
declared  the  impasse  he  found  as  "an  excellent  case  of  bad 
communication."  Notwithstanding  his  interpretation,  the  process  of 
designing  the  3PA  system  represents  an  excellent  case  of  negotiation. 
The  point  is  that  not  that  the  Capital  City-dominated  design  team 
misunderstood  what  Reason  and  Frisco  wanted  (different  things, 
incidentally),  but  that  they  hoped  instead  to  substitute  their  own  goals 
for  those  of  the  division  management  team.   That  Frisco  "stopped  them 
cold"  is  beside  the  point  here.  The  point  is  they  tried,  as  will  all 
committed  users  given  a  genuine  opportunity.  True  participation  is  a 
process  of  negotiation  among  users  and  designers,  each  attempting  to 
impose  his  or  her  a)  view  of  the  situation,  b)  solution  to  the  problem 
or  c)  objectives  based  on  self-interests.  The  danger  of  opening  up  a 
design  process  through  user  participation  is  that  some  users  may  succeed 
in  advancing  their  aims  to  the  detriment  of  the  goals  of  other  groups. 
The  corresponding  benefit  of  true  participation  is  that  through  the 
process  of  design  negotiation,  parties  to  the  process  frequently  resign 
themselves  to  tradeoffs  in  costs  and  benefits.  When  the  system  is 
finally  installed,  most  of  the  potential  resistance  has  been  already 
worked  through,  and,  if  the  design  phase  takes  somewhat  longer,  ease  of 
implementation  is  the  reward. 
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